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© A hybrid public key algorithm/data encryption algorithm key distribution method based on control 
vectors. 



© The patent describes a method and apparatus 
for securely distributing an initial Data Encryption 
Algorithm (DEA) key-encrypting key by encrypting a 
key record (consisting of the key-encrypting key and 
control information associated with that key-encryp- 
ting key) using a public key algorithm and a public 
^ key belonging to the intended recipient of the key 
^ record. The patent further describes a method and 
^ apparatus for securely recovering the distributed 
<0 key-encrypting key by the recipient by decrypting 
^1 the received key record using the same public key 
3) algorithm and private key associated with the public 
^ key and re-encrypting the key-encrypting key under 
W a key formed by arithmetically combining the recipi- 
q ent's master key with a control vector contained in 

CL 
UJ 



the control information of the received key record. 
Thus the type and usage attributes assigned by the 
originator of the key-encrypting key in the form of a 
control vector are cryptographically coupled to the 
key-encrypting key such that the recipient may only 
use the received key-encrypting key in a manner 
defined by the key originator. 

The patent further describes a method and ap- 
paratus to improve the integrity of the key distribu- 
tion process by applying a digital signature to the 
key record and by including identifying information 
(i.e., an originator identifier) in the control information 
of the key record. The integrity of the distribution 
process is enhanced by verifying the digital signa- 
ture and originator identifier at the recipient node. 
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The invention disclosed broadly relates to data 
processing systems and methods and more par- 
ticularly relates to cryptographic systems and 
methods for use in data processing systems to 
enhance security. 

The following patents are related to this inven- 
tion and are incorporated herein by reference: 

B. Brachtl, et al., "Controlled Use of Cryp- 
tographic Keys Via Generating Stations Established 
Control Values," USP 4,850,017, issued July 18, 
1989, assigned to IBM Corporation, and incorpo- 
rated herein by reference. 

S. M. Matyas, et al., "Secure Management of 
Keys Using Control Vectors," USP 4,941,176, is- 
sued July 10, 1990, assigned to IBM Corporation 
and incorporated herein by reference. 

S. M. Matyas, et al., "Data Cryptography 
Operaions Using Control Vectors," USP 4,918,728, 
issued April 17, 1990. assigned to IBM Corporation, 
and incorporated herein by reference. 

S. M. Matyas, et al., "Personal Identification 
Number Processing Using Control Vectors," USP 

4.924.514, issued May 8, 1990, assigned to IBM 
Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Secure Management of 
Keys Using Extended Control Vectors," USP 

4.924.515, issued May 8, 1990, assigned to IBM 
Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Secure Key Management 
Using Programmable Control Vector Checking," 
USP 5,007,089, issued April 9, 1991, assigned to 
IBM Corporation and incorporated herein by refer- 
ence. 

B. Brachtl, et al., "Data Authentication Using 
Modification Detection Codes Based on a Public 
One Way Encryption Function," USP 4,908,861, 
issued March 13, 1990, assigned to IBM Corpora- 
tion and incorporated herein by reference. 

D. Abraham, et al., "Smart Card Having Exter- 
nal Programming Capability and Method of Making 
Same," serial number 004,501, filed January 19, 
1987, assigned to IBM Corporation, and incorpo- 
rated herein by reference. 

S. M. Matyas, et al., "Method and Apparatus 
for Controlling the Use of a Public Key, Based on 
the Level of import Integrity for the Key," serial 
number 07/602,989, filed October 24, 1990, as- 
signed to the IBM Corporation. 

S. M. Matyas, et al., "Secure Key Management 
Using Programmable Control Vector Checking," 
USP 5,007,089, issued April 9, 1991, assigned to 
IBM Corporation and incorporated herein by refer- 
ence. 

The cryptographic architecture described in the 
cited patents by S. M. Matyas, et al. is based on 
associating with a cryptographic key, a control vec- 
tor which provides the authorization for the uses of 
the key intended by the originator of the key. The 



cryptographic architecture described in the cited 
patents by S. M. Matyas, et al. is based on the 
Data Encryption Algorithm (DEA), whereas the 
present invention is based on both a secret key 

s algorithm, such as the DEA, and a public key 
algorithm. Various key management functions, data 
cryptography functions, and other data processing 
functions are possible using control vectors, in ac- 
cordance with the invention. A system administrator 

io can exercise flexibility in the implementation of his 
security policy by selecting appropriate control 
vectors in accordance with the invention. A cryp- 
tographic facility (CF) in the cryptographic architec- 
ture is described in the above cited patents by S. 

75 M. Matyas, et al. The CF is an instruction proces- 
sor for a set of cryptographic instructions, im- 
plementing encryption methods and key generation 
methods. A memory in the crypto facility stores a 
set of internal cryptographic variables. Each cryp- 

20 tographic instruction is described in terms of a 
sequence of processing steps required to transform 
a set of input-parameters to a set of output param- 
eters. A cryptographic facility application program 
is also described in the referenced patents and 

25 patent applications, which defines an invocation 
method, as a calling sequence, for each cryp- 
tographic instruction consisting of an instruction 
mnemonic and an address with corresponding in- 
put and output parameters. 

30 Public key encryption algorithms are described 
in a paper by W. Diffie and M. E. Hellman entitled 
"Privacy and Authentication: An Introduction to 
Cryptography," Proceedings of the IEEE, Vol. 67, 
No. 3, March 1979, pp. 397-427. Public key sys- 

35 terns are based on dispensing with the secret key 
distribution channel, as long as the channel has a 
sufficient level of integrity. In a public key crypto 
system, two keys are used, one for enciphering 
and one for deciphering. Public key algorithm sys- 

40 terns are designed so that it is easy to generate a 
random pair of inverse keys PU for enciphering 
and PR for deciphering and it is easy to operate 
with PU and PR, but is computationally infeasible 
to compute PR from PU. Each user generates a 

as pair of inverse transforms, PU and PR. He keeps 
the deciphering transformation PR secret, and 
makes the enciphering transformation PU public by 
placing it in a public directory. Anyone can now 
encrypt messages and send them to the user, but 

so no one else can decipher messages intended for 
him. It is possible, and often desirable, to encipher 
with PU and decipher with PR. For this reason, PU 
is usually referred to as a public key and PR is 
usually referred to as a private key. A corollary 

55 feature of public key crypto systems is the provi- 
sion of a digital signature which uniquely identifies 
the sender of a message. If user A wishes to send 
a signed message M to user B, he operates on it 
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with his private key PR to produce the signed 
message S. PR was used as A's deciphering key 
when privacy was desired, but it is now used as his 
"enciphering" key. When user B receives the mes- 
sage S, he can recover the message M by operat- 
ing on the ciphertext S with A's public PU. By 
successfully decrypting A's message, the receiver 
B has conclusive proof it came from the sender A. 
Examples of public key cryptography are provided 
in the following U. S. patents: 

USP 4,218,582 to Hellman, et al., "Public Key 
Cryptographic Apparatus and Method;" USP 
4,200,770 to Hellman, et al., "Cryptographic Ap- 
paratus and Method;" and USP 4,405,829 to Riv- 
est, et al., "Cryptographic Communications System 
and Method," which discloses the RSA public-key 
algorithm. 

In general, it is preferable for performance rea- 
sons to use symmetric algorithms such as the Data 
Encryption Algorithm (DEA) bulk data encryption 
rather to use a public key algorithm for such pur- 
poses. However to use DEA both the data origina- 
tor and intended recipient must first share a com- 
mon, secret key. This requires the secure distribu- 
tion of at least one DEA key for each secure 
"channel" between originator and recipient. The 
problem can be reduced to distributing one secret 
DEA key-encrypting key (KEK) between the origi- 
nating node and receiving node, and thereafter 
transmitting all other DEA keys encrypted under 
this common KEK. The usual method of distributing 
the initial KEK is via trusted couriers. 

It is well-known that a hybrid system employ- 
ing a public key algorithm and the DEA may be 
effective in solving the initial KEK distribution prob- 
lem, while still retaining the faster bulk data encryp- 
tion capabilities of the DEA. In such a hybrid cryp- 
tographic system A, a public key PU is transmitted 
with integrity (see S. M. Matyas, et al., "Method 
and Apparatus for Controlling the Use of a Public 
Key, Based on the Level of Import Integrity for the 
Key", serial number 07/602,989, filed October 24, 
1990) to a second hybrid cryptographic system B. 
A secret DEA KEK, say KK, is generated and 
encrypted under PU at system B and transmitted 
to system A. System A uses the corresponding 
private key PR to decrypt KK. KK may then be 
used with the DEA algorithm to distribute additional 
DEA keys for use by systems A and B. 

Prior art, however, has not provided a cryp- 
tographically secure means to define the type and 
to control the usage of the generated KEK to insure 
that the type and uses defined by the originator of 
the key (system B) are enforced at both the origi- 
nating node and the recipient node (system A). 
Without such controls (as described in S. M. 
Matyas, et al., "Secure Management of Keys Using 
Control Vectors", USP 4,941,176, issued July 10, 



1990), the distributed KEK may be subject to mis- 
use by either party to weaken the security of the 
system (e.g., by allowing the KEK to be used in a 
data decrypt operation and thus allowing DEA keys 

s encrypted under the KEK to be decrypted and 
exposed in the clear). 

While the prior art addresses the concept of 
unidirectional key-encrypting keys, i.e., key-encryp- 
ting keys that establish a key distribution channel 

10 in one direction only, the method for establishing, 
with integrity, such a unidirectional channel using a 
public key algorithm has not been addressed. To 
accomplish this, a unique Environment Identifier 
(EID) is stored at each cryptographic device such 

75 that a distributed key-encrypting key can be im- 
ported only at the designated receiving device, but 
it does not allow the key-encrypting key to be 
imported or re-imported at the sending device, as 
described below. 

20 The originating node B generates the KEK in 
two forms: one form to be exported to the recipient 
node A (encrypted under the PU received from A) 
and a second form to be used at B ultimately to 
either export or import additional DEA keys 

25 (encrypted under some form of the local master 
key). As was described in the above reference U. 
S. patent 4,941,176, "Secure Management of Keys 
Using Control Vectors," it is critical to the security 
of each cryptographic system that the type and 

30 usage attributes of a given KEK on one system be 
limited to either EXPORTER usage or IMPORTER 
usage, but never both. Correspondingly, it must not 
be possible to generate or introduce two copies of 
the same KEK into the system, one with EXPORT- 

35 ER usage and one with IMPORTER usage. Such a 
pair of key forms is known as a bi-functional key 
pair. 

Prior art has provided no cryptographically se- 
cure means to insure that the generated KEK can- 

40 not be re-imported into the originating node to form 
a bi-functional key pair. Since key PU is public, 
system A cannot be certain that system B is the 
originator of the generated KEK. 

It is therefore a main object of the invention to 

45 provide an improved method for distributing DEA 
keys using a public key crypto system. 

It is another object of the invention to provide 
an improved method of distributing a DEA key- 
encrypting key using a public key crypto system. 

so It is another object of the invention to provide 
an improved method of distributing a DEA key- 
encrypting key that does not require the use of 
couriers. 

It is another object of the invention to provide 
55 control information associated with a distributed 
key, which defines the type and usage of the 
distributed key. 
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It is another object of the invention to provide a 
means to cryptographically couple the control in- 
formation and key using a public-key algorithm. 

It is another object of the invention to provide 
control information that prevents a distributed key 
from being imported at the originating device. 

It is another object of the invention to provide a 
method of key distribution which is compatible with 
a key management based on control vectors (in the 
above referenced patents). 

It is another object of the invention to provide a 
method of key distribution that does not also pro- 
vide a covert privacy channel. 

It is another object of the invention to provide a 
means for a receiving device to validate that a 
received distributed key has originated with an 
expected originating device. 

It is another object of the invention to provide a 
means for a distributed key to be authenticated on 
the basis of a signature generated on the distrib- 
uted key by the cryptographic system software. 

It is still a further object of the invention to 
provide a higher integrity means for a distributed 
key to be authenticated on the basis of a signature 
generated on the distributed key as an integral part 
of the cryptographic system hardware export func- 
tion. 

These and other objects, features, and advan- 
tages are accomplished by the invention disclosed 
herein. A method and apparatus are disclosed for 
generating and distributing a DEA key-encrypting 
key from a sending device implementing a public- 
key cryptographic system to a receiving device 
implementing a public-key cryptographic system. 
The method and apparatus find application in a 
cryptographic system implementing both a sym- 
metric encryption algorithm, such as the Data En- 
cryption Standard, and an asymmetric encryption 
algorithm, such as the RSA public-key algorithm. 
The method begins by generating a key-encrypting 
key at a sending device and producing two encryp- 
ted copies of the generated key. The generated 
key is encrypted first under the public key of a 
designated receiving device and the encrypted key 
is then electronically transmitted to the receiving 
device. The generated key is also encrypted under 
the master key of the sending device and stored in 
a key storage for later use in a DEA key manage- 
ment scheme for distributing further DEA keys to 
the designated receiving device. At the receiving 
device, the encrypted key is decrypted using the 
private key of the receiving device and the clear 
key is then re-encrypted under the master key of 
the receiving device and the encrypted key is 
stored in a key storage for later use in a DEA key 
management scheme for receiving further DEA 
keys from the same sending device. In accordance 
with the invention, the method of key distribution 



makes use of a key block containing the distributed 
key-encrypting key and control information asso- 
ciated with the distributed key, which includes a 
control vector to limit uses of the key and an 
s environment ID to identify the sender of the key. 
The method of key distribution also makes use of 
an optional digital signature generated on the en- 
crypted key block at the originating device and 
validated at the receiving device. 
10 These and other objects, features, and advan- 
tages of the invention will be more fully appre- 
ciated with reference to the accompanying figures. 

Fig. 1 illustrates a communications network 10 

including a plurality of data processors, each of 
75 which includes a cryptographic system; 

Fig. 2 is a block diagram of a cryptographic 

system 22; 

Fig. 3 is a block diagram of a cryptographic 
facility 30; 

20 Fig. 4 is a block diagram showing the public and 
private keys that must first be initialized at two 
cryptographic systems A and B in order that 
they may electronically distribute DEA keys us- 
ing a public key algorithm; 

25 Fig. 5 is a block diagram illustrating DEA key 
distribution using the GKSP and IDK instructions 
without digital signatures; 
Fig. 6 is a block diagram of a key block; 
Fig. 7 is a block diagram of an external key 

30 token; 

Fig. 8 is a block diagram illustrating DEA key 
distribution using the GKSP and IDK instructions 
with digital signatures; 

Fig. 9 is a block diagram of the Generate Key 
35 Set PKA (GKSP) instruction; 

Fig. 10 is a block diagram of the Import DEA 
Key (IDK) instruction; 

Fig. 1 1 is a block diagram of control vectors for 
public and private keys used for key distribution 

40 (i.e., key management purposes); 

Fig. 12 is a block diagram depicting an encryp- 
ted channel and a clear channel between two 
cryptographic systems A and B; 
Fig. 13 is a block diagram illustrating the pro- 

45 cessing of control information at a receiving 
cryptographic device; 

Fig. 14 is a block diagram of a cryptographic 
facility at a sending location, in accordance with 
the invention; 

so Fig. 15 is a block diagram of a cryptographic 
facility at a receiving location, in accordance 
with the invention; 

Fig. 16 is a block diagram of the crypto-variable 
retrieval means 40 which is a component of the 
55 cryptographic facility shown in Fig. 14. 

Environment Description: Fig. 1 illustrates a 
network block diagram showing a communications 
network 10 to which is connected a plurality of data 
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processors including data processor 20, data pro- 
cessor 20', and data processor 20". Also included 
in each data processor is a cryptographic system, 
as shown in Fig. 1. Data processor 20 includes 
cryptographic system 22, data processor 20' in- 
cludes cryptographic system 22' and data proces- 
sor 20" includes cryptographic system 22". Each 
data processor supports the processing of one or 
more applications which require access to cryp- 
tographic services such as for the encryption, de- 
cryption and authenticating of application data and 
the generation and installation of cryptographic 
keys. The cryptographic services are provided by a 
secure cryptographic facility in each cryptographic 
system. The network provides the means for the 
data processors to send and receive encrypted 
data and keys. Various protocols, that is, formats 
and procedural rules, govern the exchange of cryp- 
tographic quantities between communicating data 
processors in order to ensure the interoperability 
between them. 

Fig. 2 illustrates the cryptographic system 22. 
In the cryptographic system 22, the cryptographic 
facility (CF) 30 has an input 37 from a physical 
interface. The cryptographic facility access pro- 
gram (CFAP) 34 is coupled to the cryptographic 
facility 30 by means of the interface 31 . The cryp- 
tographic key data set (CKDS) 32 is connected to 
the cryptographic facility access program 34 by 
means of the interface 33. The application pro- 
grams (APPL) 36 are connected to the crypto- 
graphic facility access program 34 by means of the 
interface 35. 

A typical request for cryptographic service is 
initiated by APPL 36 via a function call to the CFAP 
34 at the interface 35. The service request includes 
key and data parameters, as well as key identifiers 
which the CFAP 34 uses to access encrypted keys 
from the CKDS 32 at the interface 33. The CFAP 
34 processes the service request by issuing one or 
more cryptographic access instructions to the CF 
30 at the interface 31 . The CF 30 may also have an 
optional physical interface 37 for direct entry of 
cryptographic variables into the CF 30. Each cryp- 
tographic access instruction invoked at the inter- 
face 31 has a set of input parameters processed 
by the CF 30 to produce a set of output param- 
eters returned by the CF 30 to the CFAP 34. In 
turn, the CFAP 34 may return output parameters to 
the APPL 36. The CFAP 34 may also use the 
output parameters and input parameters to subse- 
quently invoke instructions. If the output param- 
eters contain encrypted keys, then the CFAP 34, in 
many cases, may store these encrypted keys in 
the CKDS 32. 

Fig. 3 illustrates the cryptographic facility 30. 
The cryptographic facility 30 is maintained within a 
secure boundary 140. The cryptographic facility 30 



includes the instruction processor 142 which is 
coupled to the cryptographic algorithms 144 which 
are embodied as executable code. The crypto- 
graphic facility environment memory 146 is coup- 

5 led to the instruction processor 142. The physical 
interface can be coupled over line 37 to the CF 
environment memory 146, as shown in the figure. 
The instruction processor 142 is coupled to the 
cryptographic facility access program (CFAP) 34 

w by means of the interface at 31. 

The instruction processor 142 is a functional 
element which executes cryptographic microin- 
structions invoked by the CFAP access instruction 
at the interface 31 . For each access instruction, the 

75 interface 31 first defines an instruction mnemonic 
or operation code used to select particular microin- 
structions for execution. Secondly a set of input 
parameters is passed from the CFAP 34 to the CF 
30. Thirdly, a set of output parameters is returned 

20 by the CF 30 to the CFAP 34. The instruction 
processor 142 executes the selected instruction by 
performing an instruction specific sequence of 
cryptographic processing steps embodied as 
microinstructions stored in cryptographic microin- 

25 struction memory 144. The control flow and subse- 
quent output of the cryptographic processing steps 
depend on the values of the input parameters and 
the contents of the CF environment memory 146. 
The CF environment memory 1 46 consists of a set 

30 of cryptographic variables, for example keys, flags, 
counters, CF configuration data, etc., which are 
collectively stored within the CF 30. The CF envi- 
ronment variables in memory 146 are initialized via 
the interface 31 , that is by execution of certain CF 

35 microinstructions which read input parameters and 
load them into the CF environment memory 146. 
Alternately, initialization can be done via an op- 
tional physical interface which permits cryptograph- 
ic variables to be loaded directly into the CF envi- 

40 ronment memory 146, for example via an attached 
key entry device. 

The physical embodiment of the cryptographic 
facility secure boundary 140, incorporates the fol- 
lowing physical security features. The physical em- 

45 bodiment resists probing by an insider adversary 
who has limited access to the cryptographic facility 
30. The term "limited" is measured in minutes or 
hours as opposed to days or weeks. The adversary 
is constrained to a probing attack at the customer's 

so site using limited electronic devices as opposed to 
a laboratory attack launched at a site under the 
control of the adversary using sophisticated elec- 
tronic and mechanical equipment. The physical 
embodiment also detects attempts at physical 

55 probing or intruding, through the use of a variety of 
electro-mechanical sensing devices. Also, the 
physical embodiment of the cryptographic facility 
30 provides for the zeroization of all internally 
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stored secret cryptographic variables. Such 
zeroization is done automatically whenever an at- 
tempted probing or intrusion has been detected. 
The physical embodiment also provides a manual 
facility for a zeroization of internally stored secret 
cryptographic variables. Reference to the Abraham, 
et al. patent application cited above, will give an 
example of how such physical security features 
can be implemented. 

Initialization of Public-Key Cryptographic Sys- 
tem: Fig. 4 illustrates two cryptographic systems, A 
and B ( that wish to communicate cryptographically 
using public key cryptography. Cryptographic sys- 
tem A generates a public and private key pair 
(PUa, PRa), where PUa is the public key of A and 
PRa is the private key of A. In like manner, cryp- 
tographic system B generates a public and private 
key pair (PUb, PRb), where PUb is the public key 
of B and PRb is the private key of B. 

Referring to Fig. 4, the cryptographic facility 30 
of cryptographic system A contains a master key 
KMa and the cryptographic facility 30' of cryp- 
tographic system B contains a master key KMb. 
KMa and KMb are ordinarily different, being equal 
only by mere chance. At cryptographic system A, 
the public key PUa is encrypted with the Data 
Encryption algorithm (DEA) using variant key 
KMa.CI to form the encrypted value eKMa.CI- 
(PUa), where KMa.CI is formed as the Exclusive 
OR product of master key KMa and control vector 
C1. Likewise, at cryptographic system A, the pri- 
vate key PRa is encrypted with the DEA using 
variant key KMa.C2 to form the encrypted value 
eKMa.C2(PRa), where KMa.C2 is formed as the 
Exclusive OR product of master key KMa and 
control vector C2. The symbol V denotes the 
Exclusive OR operation. The encrypted values 
eKMa.C1(PUa) and eKMa.C2(PRa) are stored in 
cryptographic key data set 32. 

The control vector specifies whether the key is 
a public or private key and contains other key 
usage control information specifying how the key 
may be used. For example, when the encrypted 
key eKMa.C2(PRa) is decrypted for use within the 
cryptographic facility 30, control vector C2 indi- 
cates to the cryptographic facility how and in what 
way the key PRa may be used. Control vector C1 
similarly controls the use of public key PUa. The 
use of the control vector to control key usage is 
described in U.S. Patents 4,850,017, 4,941,176, 
4,918,176, 4,924,514, 4924,515, and 5,007,089 
cited in the background art and in co-pending 
patent application serial number 07/602,989 also 
cited in the background art. Fig. 11 illustrates con- 
trol vectors that define public and private keys, 
where the public and private keys are key manage- 
ment keys used by the cryptographic system to 
distribute DEA keys. The fields in each control 



vector consist of a CV TYPE, which specifies 
whether the control vector is a public or a private 
key and additionally whether the key pair is a key 
management key pair for use in distributing DEA 

5 keys or whether the key pair is some other kind of 
key pair. Other types of key pairs are possible, 
such as user keys which can be used for genera- 
tion and verification of digital signatures but not for 
key distribution. Each control vector has a PR 

10 USAGE and PU USAGE field. For the public key 
control vector, the PU USAGE field controls the 
usage of the public key in cryptographic instruc- 
tions whereas the PR USAGE field is only informa- 
tional. For the private key control vector, the PR 

75 USAGE field controls the usage of the private key 
in cryptographic instructions whereas the PU US- 
AGE field is only informational. The ALGORITHM 
field indicates the public key algorithm to which 
this key pair pertains. The HIST field records his- 

20 tory information, e.g., the options used to import a 
public key (see co-pending patent application serial 
number 07/602,989 as cited in the background art, 
which describes the use of history information 
fields in the public key control vector). The reader 

25 will appreciate that the control vector may contain a 
variety of different control vector fields for the 
purpose of controlling the operation and use of the 
key within the cryptographic network and cryp- 
tographic systems within the network. 

30 In an alternate embodiment, the public key 
PUa may be stored in an unencrypted form, since 
there is no intent to keep the value of this key 
secret. Encrypting PUa is done for sake of uniform- 
ity, so that all keys in the cryptographic key data 

35 set 32 are stored and recovered using one com- 
mon method. Those skilled in the art will also 
recognize that the length of PUa and PRa will likely 
be different than the block size of the DEA, which 
is 64 bits, and hence PUa and PRa may need to 

40 be encrypted in separate 64-bit pieces. The par- 
ticular method for encrypting PUa and PRa is un- 
important to the invention. However, one way that 
this encryption can be carried out is to use the 
Cipher Block Chaining (CBC) mode of DEA encryp- 

45 tion described in DES modes of operation, Federal 
Information Processing Standards Publication 81, 
National Bureau of Standards, US Department of 
Commerce, December 1980. In cases where KMa 
is a 128-bit key, the CBC mode of DEA encryption 

so can be adapted to encrypt PUa under KMa. PUa is 
first encrypted with the leftmost 64 bits of KMa, 
then decrypted with the rightmost 64 bits of KMa, 
and then encrypted again with the leftmost 64 bits 
of KMa. 

55 In like manner, at cryptographic system B, the 
public and private keys, PUb and PRb, are encryp- 
ted with master key KMb and control vectors C3 
and C4, per the same method described for cryp- 
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tographic system A. The encrypted values 
eKMb.C3(PUb) and eKMb.C4(PRb) are stored in 
cryptographic key data set 32'. Control vectors C3 
and C4 control the usage of PUb and PRb, respec- 
tively. 

Although encryption of the public and private 
keys has been described in terms of a DEA-based 
master key, those skilled in the art will appreciate 
that the DEA could be replaced by a public key 
algorithm and the master keys could be replaced 
by a PKA-based key pair used for this purpose. 
Moreover, the encryption of the public and private 
keys has been described in terms of encryption of 
the keys only. In some implementations it may be 
more practical to imbed these keys within key 
records that contain other key-related information 
besides the keys themselves. 

In order for cryptographic systems A and B to 
carry out cryptographic operations using their re- 
spective implemented public key algorithms, they 
must share their public keys with each other. Thus, 
at cryptographic system A a function exists that 
permits the encrypted value eKMa.CI(PUa) to be 
accessed from cryptographic key data set 32 and 
decrypted so that the clear value of PUa may be 
exported to cryptographic system B at 300. At 
cryptographic system B a function exists that per- 
mits the clear value of PUa to be imported and 
encrypted under the variant key KMb.CI. The so- 
imported encrypted value eKMb.Cl(PUa) is then 
stored in cryptographic key data set 32'. In like 
manner, functions exist at B and A that permit 
public key PUb to be decrypted at B, sent to A at 
301, and re-encrypted at A for storage in A's cryp- 
tographic key data set. 

Co-pending patent application by S. M. Matyas 
et al., serial number 07/602,989, "Method and Ap- 
paratus for Controlling the use of a Public Key, 
Based on the Level of Import Integrity for the Key," 
describes a method for generating public and pri- 
vate keys and for distributing public keys in order 
to initialize a public-key cryptographic system, and 
is incorporated by reference herein. 

Key Distribution: Fig. 5 illustrates the process 
by which cryptographic system A may distribute a 
key to cryptographic system B using a public key 
algorithm (PKA). That is, it illustrates the process of 
key distribution using a PKA. In a hybrid key dis- 
tribution scheme, the distributed key is a DEA key, 
e.g., an initial key-encrypting key to be used later 
with a DEA-based key distribution scheme to dis- 
tribute all subsequent DEA keys. However, any key 
can be distributed using the so-described PKA- 
based key distribution scheme, including both DEA 
keys and PKA keys. The distributed DEA and PKA 
keys can be of any type or designated use. How- 
ever, for purposes of illustration, Fig. 5 shall as- 
sume that the distributed key is a DEA key. 



Referring to Fig. 5, the steps involved in dis- 
tribution of a key from cryptographic system A to 
cryptographic system B are these. At cryptographic 
system A, a Generate Key Set PKA (GKSP) in- 

s struction is executed within the CF 30. Control 
information at 303 is provided to the GKSP instruc- 
tion as input. In response, the GKSP instruction 
generates a key K and produces two encrypted 
copies of K, which are returned by the GKSP 

jo instruction at 305 and 306. The first encrypted 
copy of K is produced by encrypting K with the 
DEA using variant key KMa.C5 formed as the Ex- 
clusive OR product of master key KMa and control 
vector C5. C5 may be input to the GKSP instruc- 
ts tion as part of the control information, at 303, or it 
may be produced within the CF 30 as part of the 
GKSP instruction, or it may be produced as a 
combination of both methods. The second encryp- 
ted copy of K is produced as follows. A key block 

20 (designated keyblk) is first formed. The key block 
includes the clear value of K, control information, 
and possibly other information unimportant to the 
present discussion, as illustrated in Fig. 6. The 
format of the keyblk is unimportant to the present 

25 discussion, and those skilled in the art will recog- 
nize that many possible arrangements of the 
keyblk information are possible. In all cases, the 
keyblk contains the necessary information to ac- 
complish the task of key distribution. The length of 

30 the keyblk is assumed to be equal to the block size 
of the public key algorithm. For example, if the 
public key algorithm is the RSA algorithm, then the 
block size is just the modulus length. Also, it is 
assumed that the numeric value of the keyblk, say 

35 its binary value, is adjusted as necessary to permit 
it to be encrypted as a single block by the public 
key algorithm. For example, if the public key al- 
gorithm is the RSA algorithm, then the keyblk is 
adjusted so that its binary value is less than the 

40 binary value of the modulus. This can be done by 
forcing the high order (most significant) bit in the 
keyblk to zero. Once the keyblk has been for- 
matted, it is encrypted with the public key PUb of 
cryptographic system B to form the encrypted val- 

45 ue ePUb(keyblk), which is returned at 306. To 
permit this to be accomplished, the encrypted val- 
ue eKMa.C3(PUb) and control vector C3 are sup- 
plied to the GKSP instruction at 304 as inputs and 
eKMa.C3(PUb) is decrypted under variant key 

so KMa.C3. KMa.C3 is formed as the Exclusive OR 
product of master key KMa stored within the CF 30 
and control vector C3. 

The first encrypted output eKMa.C5(K) at 305 
is stored in the cryptographic key data set 22 of 

55 cryptographic system A. Control vector C5 is also 
stored in the cryptographic key data set 22 to- 
gether with the encrypted key eKMa.C5(K). In 
some implementations it may be convenient to 
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store eKMa.C5(K) and C5 in an internal key token 
together with other key-related information. The 
internal key token is not relevant to the present 
discussion, and is therefore not shown in Fig. 5. If 
C5 is generated within the CF 30, it may also be 
provided as an output at 305 so that it may be 
store in CKDS 22. 

The second encrypted output ePUb(keyblk) at 
306 is formatted within an external key token 308. 
The external key token contains the encrypted key 
or encrypted key block ePUb(keyblk), control in- 
formation, and other information unimportant to the 
present discussion, as shown in Fig. 7. The control 
information supplied as input to the GKSP instruc- 
tion at 303 is also stored in external key token 308 
at 307. However, the control information at 307 
may include additional information available to the 
cryptographic facility access program (CFAP) 
which is not specified as an input to the GKSP 
instruction at 303. In other words, the source of the 
control information in the external key token 308 
may be much broader than the control information 
supplied as input the the GKSP instruction at 303. 
One example, is the Environment Identifier (EID) 
value stored both in the CF 30 and in the CFAP. 
The EID value is an identifier that uniquely iden- 
tifies each cryptographic facility or cryptographic 
system within a network. The EID value is loaded 
into the CF 30 during an initialization sequence 
prior to performing routine cryptographic operations 
within the cryptographic system. Another example 
of initialization is the loading of the master key 
KMa. The EID value need not be supplied to the 
CF since it is already stored in the CF. But the EID 
value may be stored within the external key token, 
in which case it is supplied as an input at 307. In 
like manner, the control information in the keyblk 
may include a control vector C6 specifying the 
usage of K at cryptographic system B. In that case, 
C6 may be supplied as part of the control informa- 
tion at 303, in which case it is also supplied as part 
of the control information at 307. If however C6 is 
generated within CF 30, then C6 is not supplied as 
part of the control information at 303, but is sup- 
plied as part of the control information at 307. 
Those skilled in the art will recognize that various 
alternatives exist for the specification or derivation 
of the necessary control information and that dif- 
ferent combinations of inputs to the GKSP instruc- 
tion and to the external key token are therefore 
possible. 

The formatted external key token 308 is trans- 
mitted to cryptographic system B where it is pro- 
cessed. The CFAP at B first checks the control 
information in the external key token for consis- 
tency. For example, if the control information con- 
tains a control vector C6, then C6 is checked to 
ensure that it represents a key type and key usage 



approved by cryptographic system B. Likewise, if 
the control information contains an EID value, then 
the EID value is checked to ensure that the exter- 
nal key token and the key to be imported origi- 

5 nated from cryptographic system A, i.e., it origi- 
nated from the expected or anticipated crypto- 
graphic system that B 'thinks* it is in communica- 
tion with and which it desires to establish a keying 
relationship. Once this has been accomplished, the 

10 received key is imported as follows. The encrypted 
keyblk, ePUb(keyblk) and part or all of the control 
information in the external key token are supplied 
as inputs to an Import DEA Key (IDK) instruction at 
309, which is executed within CF 30' at cryp- 

75 tographic system B. In response, the IDK instruc- 
tion decrypts ePUb(keyblk) under the private key 
PRb belonging to cryptographic system B. To per- 
mit this to be accomplished, the encrypted value 
eKMb.C4(PRb) and control vector C4 are supplied 

20 to the IDK instruction at 310 as inputs and 
eKMb.C4(PRb) is decrypted under variant key 
KMb.C4. KMb.C4 is formed as the Exclusive OR 
product of master key KMb stored within the CF 
30' and control vector C4. Once ePUb(keyblk) has 

25 been decrypted and the clear value of keyblk has 
been recovered, the keyblk is processed as fol- 
lows. The control information contained in the 
keyblk is checked for consistency against the con- 
trol information, or reference control information, 

30 supplied as input at 309. If the consistency check- 
ing is satisfactory (okay), then the clear value of K 
is extracted from keyblk and it is encrypted with 
the variant key KMb.C6 to produce the encrypted 
key value eKMb.C€(K). KMb.C6 is formed as the 

35 Exclusive OR product of master key KMb stored 
within CF 30* and control vector C6. Control vector 
C6 may be obtained in different ways. C6 may be 
contained in the control information in keyblk, in 
which case it is extracted from keyblk. In other 

40 cases, C6 may be produced within CF 30'. For 
example, if there is only one key type and key 
usage permitted, then C6 can be a constant stored 
within the IDK instruction. The so-produced encryp- 
ted key value eKMb.C6(K) is provided as an output 

45 of the IDK instruction at 31 1 , and is stored together 
with its control vector C6 within CKDS 22'. The 
value of C6 stored in CKDS 22' is obtained either 
from the control information input to the IDK in- 
struction at 309 or, if C6 is not in the control 

so information input to the IDK instruction at 309, then 
it is produced by the CFAP in the same way that it 
is produced by the IDK instruction and stored in 
CKDS 22'. Alternatively, C6 could be returned as 
an output of the IDK instruction. Those skilled in 

55 the art will realize that several alternatives exist for 
obtaining C6 depending on how and where it is 
produced within the cryptographic system and 
whether it is or is not included as part of the 
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control information in the external key token. 

In the preferred embodiment, the control in- 
formation at 303 supplied to the GKSP instruction 
includes a specification of control vectors C5 and 
C6. This allows the GKSP instruction the freedom 
and flexibility to generate two encrypted copies of 
key K that have different key types and usages, as 
specified by C5 and C6. In that case, the GKSP 
instruction must incorporate some control vector 
checking to determine that C5 and C6 constitutes a 
valid pair. The various options for control vector 
design and checking pursued here are based on 
the control vector designs included in prior art, 
cited in the background art, and already discussed. 
Likewise, in the preferred embodiment, control vec- 
tor C6 is included in the control information in the 
key block (keyblk) and also in the control informa- 
tion in the external key token. This permits the 
receiving cryptographic system to import keys of 
different types while still permitting the receiving 
system to verify that the imported key is one that it 
wants or expects. This is accomplished by the 
CFAP first checking the control vector in the exter- 
nal key token to make sure that it prescribes a key 
type and key usage that it expects or will allow to 
be imported. C6 is then supplied as an input in the 
control information at 309 to the CF 30'. At the time 
the IDK instruction recovers the clear value of 
keyblk, the value of C6 in the control information in 
keyblk is checked against the value of C6, or the 
reference value of C6, supplied as input. This per- 
mits the CF to verify that the value of C6 used to 
import the key K is the same control vector C6 in 
the external key token. Otherwise, if this check was 
ignored it would be possible for an adversary to 
substitute C6' for C6 in the external key token, 
causing a key to be imported that the CFAP may 
not permit. 

In the preferred embodiment, each crypto- 
graphic facility stores a unique EID value, e.g., a 
128-bit value set within the CF during an initializa- 
tion sequence before routine operations are permit- 
ted. At the time a keyblk is prepared within the CF 
by a GKSP instruction, the EID value is obtained 
from the CF and included within the control in- 
formation in the keyblk. In like manner, a duplicate 
copy of the EID value is stored outside the CF with 
integrity such that it is available to the CFAP. This 
EID value is obtained by the CFAP and is included 
within the control information in the external key 
token. Thus, the CFAP at the receiving crypto- 
graphic system can check the EID value in the 
control information of the received external key 
token to ensure that the external key token origi- 
nated from the cryptographic system that is ex- 
pected or anticipated. That is, B knows that the 
external key token came from A, which is what is 
expected. The EID value is also supplied as part of 



the control information at 309. Thus, when the IDK 
instruction obtains the clear keyblk, the EID value 
in the control information in the clear keyblk can be 
checked against the EID value, or reference EID 

5 value, supplied as an input. In this way, the CFAP 
is sure that the IDK instruction will import K only if 
the two EID values are equal. This prevents an 
adversary from changing the EID value in the ex- 
ternal key token to a different value that might also 

io be accepted by the receiving device. This might 
lead to a situation where B imports a key from A, 
thinking that it came from C. 

The EID also serves another purpose, as now 
described. At the time the clear value of keyblk is 

is obtained by the IDK instruction, a check is per- 
formed to ensure that the value of EID in the 
control information in keyblk is not equal to the 
value of EID stored in the CF at the receiving 
device. Thus, the encrypted value of ePUx(keyblk) 

20 produced at cryptographic system A, where PUx 
may be the public key of any cryptographic system 
in the network, including A itself, cannot be im- 
ported by A. This prevents an adversary at A, who 
specifies his own public key PUa to the GKSP 

25 instruction, from importing ePUa(keyblk) at A and 
thereby obtaining two encrypted copies eKMa.CS- 
(K) and eKMa.C6(K) of the same key with poten- 
tially different key types and key usage attributes. 
In some cases, bi-functional key pairs are undesira- 

30 ble and the key management design will specifi- 
cally disallow such key pairs to be created using 
the key generation facilities provided by the key 
management services. 

Key Distribution with Digital Signatures: The 

as key distribution scheme described in Fig. 5 is not 
by itself the preferred embodiment of the invention. 
This is so because, as it stands, the scheme can 
be attacked by an adversary who knows the public 
value of B's key, PUb. In public key cryptographic 

40 systems, one naturally makes the assumption that 
PUb is known by anyone, even an adversary. The 
adversary can forge values of keyblk containing 
DEA keys of his choosing and freely encrypt these 
key blocks under PUb. Thus, at B, there is no way 

45 to know that an imported key originated with A or 
with an adversary posing as A. The importing func- 
tion will import the forged values of keyblk, which 
results in known values of K being encrypted under 
the master key, of the form eKMb.C6(K), and 

so stored in CKDS 22'. In that case, data or keys 
encrypted under K are easily deciphered by the 
adversary who knows K. 

The preferred embodiment of the invention 
therefore includes a means by which the receiver, 

55 say cryptographic system B, can ensure that a 
received encrypted keyblk of the form ePUb- 
(keyblk) did in fact originate with the intended 
sender, say cryptographic system A. To accom- 
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plish this, the GKSP instruction at cryptographic 
system A produces a digital signature (designated 
DSIGa) on ePUb(keyblk) using its private key PRa. 
The so-produced digital signature is transmitted 
together with the external key token to crypto- 
graphic system B where the key is imported using 
an IDK instruction. In this case, the IDK instruction 
first verifies the digital signature DSIGa using the 
previously imported copy of PUa received from 
cryptographic system A. Only after DSIGa has 
been successfully verified will the IDK instruction 
continues as already described in Fig. 5 and import 
the key K. 

Fig. 8 illustrates the scheme for DEA key dis- 
tribution with digital signatures, which is the same 
as the scheme shown in Fig. 5 except as follows. 
Once the encrypted key value ePUb(keyblk) has 
been produced, the GKSP instruction additionally 
produces the digital signature DSIGa from ePUb- 
(keyblk) and the private key PRa belonging to 
cryptographic system A. A common method for 
producing such a signature is to first calculate a 
hash value on ePUb(keyblk) using a one way cryp- 
tographic function, such as described in U. S. pat- 
ent 4,908,861 by Brachtl et al., cited in the back- 
ground art, which uses either two DEA encryptions 
or four DEA encryptions per each 64 bits of input 
text to be hashed, and then decrypt (or transform) 
the hash value using the private key PRa to pro- 
duce a DSIGa of the form dPRa(hash value). The 
clear value of PRa is obtained by decrypting the 
encrypted value of eKMa.C2(PRa) supplied as an 
input to the GKSP instruction at 313 using the DEA 
and the variant key KMa.C2. KMa.C2 is formed as 
the Exclusive OR product of master key KMa 
stored in CF 30 and control vector C2 supplied as 
input to the GKSP instruction at 313. For example, 
if the public key algorithm is the RSA algorithm, a 
the digital signature may be calculated using the 
method as described in ISO Draft International 
Standard 9796 entitled "Information Technology -- 
Security Techniques -- Digital Signature Scheme 
Giving Message Recovery." The so-produced 
DSIGa 315 is returned as an output at 314. Both 
the external key token 308 and the DSIGa 315 are 
transmitted to cryptographic system B. At cryp- 
tographic system B, the IDK instruction is used to 
import the key K in similar fashion as described in 
Fig. 5 except that the IDK instruction first validates 
DSIGa using the public key PUa previously im- 
ported, encrypted, and stored in CKDS 22'. A 
DSIGa of the form dPRa(hash value) is validated by 
encrypting dPRa(hash value) with PUa, calculating 
a hash value on ePUb(keyblk) using the same one 
way cryptographic function, called the hash value 
of reference, and comparing the hash value of 
reference and the recovered clear hash value for 
equality. Only if this comparison check is success- 



ful does the IDK instruction continue and import the 
key K. The clear value of PUa is obtained by 
decrypting the encrypted value of eKMb.CI(PUa) 
supplied as an input to the IDK instruction at 316 

5 using the DEA and the variant key KMb.CI. 
KMb.CI is formed as the Exclusive OR product of 
master key KMb stored in CF 30' and control 
vector C1 supplied as input to the IDK instruction 
at 316. Thus, the GKSP instruction at cryptographic 

ro system A produces DSIGa and the IDK instruction 
at cryptographic system B verifies DSIGa. In an 
alternate embodiment, DSIGa can be calculated by 
the CF 30 using a separate instruction for generat- 
ing digital signatures. In that case, after the GKSP 

/5 instruction has been executed, the CFAP invokes 
the generate digital signature instruction causing 
DSIGa to be generated. In like manner, DSIGa can 
be verified by the CF 30' using a separate instruc- 
tion for verifying digital signatures. In that case, 

20 before the IDK instruction is invoked, the CFAP 
invokes the verify digital signature instruction to 
ensure that DSIGa is valid. 

Generate Key Set PKA (GKSP) Instruction: Fig. 
9 illustrates the Generate Key Set PKA (GKSP) 

25 instruction. The GKSP instruction of Fig. 9 is iden- 
tical to the GKSP instruction contained within the 
CF 30 of Fig. 8. The GKSP instruction generates a 
two encrypted copies of a generated DEA key K. 
The first copy is of the form eKM.C5(K) and is 

30 stored in the cryptographic key data set of the 
generating cryptographic device, say A. The sec- 
ond copy is of the form ePU(keyblk) and is trans- 
mitted to a designated receiving cryptographic de- 
vice, say B, where the public key PU belonging to 

35 the receiving cryptographic device B. Also, the 
GKSP instruction produces a digital signature DSIG 
on ePU(keyblk) using the private key PR of the 
generating cryptographic device A. DSIG is also 
transmitted to cryptographic device B to serve as 

40 proof that ePU(keyblk) was produced at crypto- 
graphic device A, i.e., produce at a valid network 
cryptographic device. 

Referring to Fig. 9, GKSP instruction 500 con- 
sists of control information retrieval means 504, PU 

45 recovery means 506, PR recovery means 507, key 
generation means 508, eKM.C5(K) production 
means 509, ePU(keyblk) production means 510, 
DSIG production means 511, and hash algorithms 
512. GKSP instruction 500 is located in instruction 

so processor 142 within cryptographic facility 30, as 
shown in Fig. 3. The inputs to the GKSP instruction 
are supplied to the GKSP instruction by CFAP 34, 
i.e., by the CFAP 34 to the CF 30 across the 
CFAP-to-CF interface. In similar manner, the out- 

55 puts from the GKSP instruction are supplied to the 
CFAP 34, i.e., by the CF 30 to the CFAP 34 across 
the CFAP-to-CF interface. 
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The inputs to GKSP instruction 500 are (1) at 
501 , control information such as control vectors C5 
and C6 that specify the key usage attributes of the 
two encrypted copies of the generated DEA key K, 
(2) at 502, control vector C3 and encrypted public 
key eKM.C3(PU), where C3 specifies the key us- 
age attributes of public key PU belonging to the 
receiving cryptographic device, and (3) at 503, 
control vector C2 and encrypted private key 
eKM.C2(PR), where C2 specifies the key usage 
attributes of private key PR belonging to the send- 
ing or generating cryptographic device. The out- 
puts from GKSP instruction 500 are (1) at 521, the 
encrypted key, eKM.C5(K) ( where K is encrypted 
under variant key KM.C5 formed as the Exclusive 
OR product of master key KM and control vector 
C5, (2) at 522, the encrypted key block, ePU- 
(keyblk), where keyblk is encrypted under public 
key PU belonging to the intended receiving cryp- 
tographic device and where keyblk is a key block 
containing the generated DEA key K, control in- 
formation, and possibly other information as de- 
picted in Rg. 6, and (3), at 523, a digital signature 
DSIG generated on ePU(keyblk) using the private 
key PR belonging to the sending or generating 
cryptographic device. 

Control information retrieval means 504 ac- 
cepts and parses control information supplied as 
input to the GKSP instruction at 501. Also, control 
information retrieval means 504 accesses control 
information stored within the secure boundary of 
the cryptographic facility, e.g., the Environment 
Identifier (EID) at 505. Control information retrieval 
means 504 may also perform consistency checking 
on the assembled control information. For example, 
control vectors C5 and C6 may be checked and 
cross checked for consistency, i.e., to ensure they 
are a valid control vector pair. GKSP instruction 
500 is aborted if C5 and C6 are incorrect or do not 
specify the correct key usage required by the 
GKSP instruction. In an alternate embodiment, it 
may be possible for control information retrieval 
means 504 to generate or produce control vector 
C6 from control vector C5, or vice versa, in which 
case only one control vector is specified in the 
control information supplied at 501. In that case, 
cross checking of C5 and C6 is unnecessary. Con- 
trol vector checking of C5 or C6 can be performed 
in control information retrieval means 504 or in 
eKM.C5(K) production means 509 if the control 
vector is C5 or in ePU(keyblk) production means 
510 if the control vector is C6. The reader will 
appreciate that control vector checking may be 
accomplished in variety of ways within the different 
components parts of the GKSP instruction, and that 
these variations do not significantly depart of the 
general framework of the invention. In any event, 
control information retrieval means 504 makes the 



control information available to other component 
parts of the GKSP instruction. C5 is passed to 
eKM.C5(K) production means 509 and EID and C6 
are passed to ePU(keyblk) production means 510. 

5 Optionally, control information may also be passed 
to DSIG production means 511 such as the iden- 
tifier or name of a hashing algorithm to be used in 
the preparation of the digital signature. The GKSP 
instruction may support only one hashing algorithm 

ro in which case the identifier or name of a hashing 
algorithm need not be passed to DSIG production 
means. Those skilled in the art will recognize that 
many possible variations exist for inputting and 
accessing control information, for parsing, checking 

75 and making the control information available to 
different component parts of the GKSP instruction. 

PU recovery means 506 decrypts input 
eKM.C3(PU) under variant key KM.C3 formed as 
the Exclusive OR product of master key KM stored 

20 in clear form within the cryptographic facility and 
directly accessible to GKSP instruction 500 and 
control vector C3 specified as an input to GKSP 
instruction 500. Prior to decrypting eKM.C3(PU), 
PU recovery means 506 performs control vector 

25 checking on C3. GKSP instruction 500 is aborted if 
C3 is incorrect or does not specify the correct key 
usage required by the GKSP instruction. Public key 
PU is stored in encrypted form so that PU Recov- 
ery means 506 will be, for all practical purposes, 

30 identical to PR Recovery means 507. Encryption of 
PU is also preferred since it permits control vector 
C3 to be cryptographically coupled with public key 
PU. Even though PU is public, and there is no 
need to protect the secrecy of PU, encryption of 

35 PU thus ensures that PU can be used only if C3 is 
correctly specified as an input to the GKSP instruc- 
tion. This ensures that PU is used by the GKSP 
instruction only if it has been so designated for 
use. In an alternate embodiment, PU could be 

40 stored outside the cryptographic facility in clear 
form and PU Recovery means 506 could be omit- 
ted from GKSP instruction 500. In this case, the 
embodiment may choose to fix the usage attributes 
of PU so that there is no chance for an adversary 

45 to specify a control vector C3 that is incorrect, i.e., 
C3 is a fixed constant value. In any event, the 
recovered clear value of PU is supplied as an input 
to ePU(keyblk) production means 510. 

PR recovery means 507 decrypts input 

so eKM.C2(PR) under variant key KM.C2 formed as 
the Exclusive OR product of master key KM stored 
in clear form within the cryptographic facility and 
directly accessible to GKSP instruction 500. Prior 
to decrypting eKM.C2(PR), PR recovery means 

55 507 performs control vector checking on C2. GKSP 
instruction 500 is aborted if C2 is incorrect or does 
not specify the correct key usage required by the 
GKSP instruction. The recovered clear value of PR 

12 
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is supplied as an input to DSIG production means 
511. 

Key generator means 508 is a pseudo random 
number generator for generating DEA keys. Alter- 
natively, key generator means 508 could be a true 
random number generator. For sake of simplicity, 
key generator means 508 generates 64-bit random 
numbers which are adjusted for odd parity. That is, 
the eight bit of each byte in the generated random 
number is adjusted so that the value in each byte 
is odd. DEA keys may contain either 64 or 128 bits 
depending on their intended usage. Data- 
encrypting-keys used for encrypting data are 64-bit 
keys. Key-encrypting-keys used for encrypting 
keys are generally 128-bit keys, but may in some 
cases be 64-bit keys. To produce a 128-bit key, 
key generator means 508 is invoked twice. The so- 
generated DEA key is supplied as an input to both 
eKM.C5(K) production means 509 and ePU(keyblk) 
production means 510. 

eKM.C5(K) production means 509 Exclusive 
ORs input KM and C5 to produce variant key 
KM.C5 and then encrypts input K with KM.C5 to 
form the encrypted output eKM.C5(K), which is 
returned to the CFAP at 521. if control vector C5 is 
not consistency checked in control information re- 
trieval means, it may alternatively be checked here. 

ePU(keyblk) production means 510 first pre- 
pares a key block, designated keyblk, from the 
inputs K, EID, and C6. and then encrypts keyblk 
with public key PU to form the encrypted output 
ePU(keyblk), which is returned to the CFAP at 522. 
If control vector C6 is not consistency checked in 
control information retrieval means, it may alter- 
natively be checked here. The value ePU(keyblk) is 
also supplied as an input to DSIG production 
means 51 1 to allow the digital signature DSIG to be 
produced. The format of keyblk is shown in Fig. 6 
and has been discussed previously. The procedure 
of preparing keyblk accomplishes two main goals. 
It ensures that all necessary information such as 
the key, control information, key-related informa- 
tion, keyblk parsing information, etc. is included 
within keyblk. Also, it ensure that keyblk is con- 
structed in a way that keyblk can be encrypted with 
PU using the public key algorithm. For example, it 
may be necessary to pad keyblk so that its length 
and binary value are such that keyblk is encrypted 
properly and in conformance with restrictions im- 
posed or that may be imposed by the public key 
algorithm. 

DSIG production means 51 1 produces a digital 
signature on ePU(keyblk) using private key PR. To 
accomplish this, a hash value is first calculated on 
ePU(keyblk) using hash algorithm 512. Hash al- 
gorithm 512 may in fact be a set of hash al- 
gorithms. In that case, the hash algorithm is se- 
lected on the basis of a hash algorithm identifier or 



other appropriate encoded value passed by the 
control information retrieval means 504 to the DSIG 
production means 511. The so-produced hash val- 
ue is then formatted in a suitable signature block 

5 and decrypted with private key PR to produce 
DSIG, which is returned to the CFAP at 523. The 
signature block can in the simplest case consist of 
the hash value and padding data, so as to con- 
struct a signature block whose length and value are 

/o in conformance with restrictions imposed or that 
may be imposed by the public key algorithm, as 
already discussed above. The DSIG production 
means 51 1 may also implement a digital signature 
method based on a national or international stan- 

75 dard, such as International Standards Organization 
draft international standard (ISO DIS) 9796. 

Import DEA Key (IDK) Instruction: Fig. 10 illus- 
trates the Import DEA Key (IDK) instruction. The 
IDK instruction of Fig. 10 is identical to the IDK 

20 instruction contained within the CF 30 of Fig. 9 The 
IDK instruction permits a cryptographic device, say 
B, to import an encrypted DEA key of the form 
ePU(keyblk) that has been received from a sending 
cryptographic device, say A. The received digital 

25 signature DSIG is used by the IDK instruction to 
verify that ePU(keyblk) originated with cryptograph- 
ic device A, i.e., at a valid network cryptographic 
device. 

Referring to Fig. 10, IDK instruction 600 con- 

30 sists of PU recovery means 606, PR recovery 
means 607, control information retrieval means 
608, hash algorithms 610, DSIG verification means 
611, keyblk recovery means 612, eKM.C6(K) pro- 
duction means 613, and control information consis- 

35 tency checking means 614. IDK instruction 600 is 
located in instruction processor 142 within cryp- 
tographic facility 30, as shown in Fig. 3. The inputs 
to the IDK instruction are supplied to the IDK 
instruction by CFAP 34, i.e., by the CFAP 34 to the 

40 CF 30 across the CFAP-to-CF interface. In similar 
manner, the outputs from the IDK instruction are 
supplied to the CFAP 34, i.e., by the CF 30 to the 
CFAP 34 across the CFAP-to-CF interface. 

The inputs to the IDK instruction 600 are (1) at 

45 601, control vector C1 and encrypted public key 
eKM.C1(PU), where C1 specifies the key usage 
attributes of public key PU belonging to the send- 
ing cryptographic device, (2) at 602, digital signa- 
ture DSIG, (3) at 603, encrypted key block ePU- 

50 (keyblk), where keyblk is encrypted under public 
key PU belonging to the the receiving cryptograph- 
ic device and where keyblk is a key block contain- 
ing the to-be-imported DEA key K, control informa- 
tion, and possibly other information as depicted in 

55 Fig. 6, (4) at 604, control vector C4 and encrypted 
private key eKM.C4(PR), where C4 specifies the 
key usage attributes of private key PR belonging to 
the receiving cryptographic device, and (5) at 605, 
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control information, such as a reference control 
vector C6 and a reference EID value of the sending 
cryptographic device. The output of the IDK in- 
struction 600 is the encrypted key eKM.C6(K), 
where K is the to-be-imported DEA key encrypted 
under variant key KM.C6 formed as the Exclusive 
OR product of master key KM and control vector 
C6. 

PU recovery means 606 decrypts input 
eKM.C1(PU) under variant key KM.C1 formed as 
the Exclusive OR product of master key KM stored 
in clear form within the cryptographic facility and 
directly accessible to IDK instruction 600 and con- 
trol vector C1 specified as an input to IDK instruc- 
tion 600. Prior to decrypting eKM.C1(PU), PU re- 
covery means 606 performs control vector check- 
ing on C1. IDK instruction 600 is aborted if C1 is 
incorrect or does not specify the correct key usage 
required by the IKK instruction. Public key PU is 
stored in encrypted form so that PU recovery 
means 606 well be, for all practical purposes, iden- 
tical to PR recovery means 607 Encryption of PU 
is also preferred since it permits control vector C1 
to be cryptographically coupled with public key PU, 
as argued previously under the description of the 
GKSP instruction. In an alternate embodiment, PU 
could be stored outside the cryptographic facility in 
clear form and PU recovery means 606 could be 
omitted from IDK instruction 600. In this case, the 
embodiment may choose to fix the usage attributes 
of PU so that there is no chance for an adversary 
to specify a control vector C1 that is incorrect, i.e., 
C1 is a fixed constant value. In any event, the 
recovered clear value of PU is supplied as an input 
to DISG verification means 61 1 . 

PR recovery means 607 decrypts input 
eKM.C4(PR) under variant key KM.C4 formed as 
the Exclusive OR product of master key KM stored 
in clear form within the cryptographic facility and 
directly accessible to IDK instruction 600. Prior to 
decrypting eKM.C4(PR), PR recovery means 607 
performs control vector checking on C4. IDK in- 
struction 600 is aborted if C4 is incorrect or does 
not specify the correct key usage required by the 
IDK instruction. The recovered clear value of PR is 
supplied as an input to keyblk recovery means 
612. 

Control information retrieval means 608 ac- 
cepts and parses control information supplied as 
input to the IDK instruction at 605. Also, control 
information retrieval means 608 accesses control 
information stored within the secure boundary of 
the cryptographic facility, e.g., the Environment 
Identifier (EID) at 609. Control information retrieval 
means 608 supplies control information to control 
information consistency checking means 614 and 
possibly to other component parts of the IDK in- 
struction, such as a hash algorithm identifier sup- 



plied to DSIG verification means 61 1 (not shown in 
Fig. 10). 

DSIG verification means 611 uses public key 
PU belonging to the sending cryptographic device 

5 to verify the digital signature DSIG generated on 
ePU(keyblk) at the sending cryptographic device. 
To accomplish this, a hash value is first calculated 
on ePU(keyblk) using hash algorithm 512. Hash 
algorithm 512 may in fact be a set of hash al- 

10 gorithms. In that case, the hash algorithm is se- 
lected on the basis of a hash algorithm identifier or 
other appropriate encoded value passed by the 
control information retrieval means 608 to the DSIG 
verification means (not shown in Fig. 10). The clear 

75 public key PU obtained from PU recovery means 
606 is then used to encrypt the value of DSIG 
specified as an input at 602. This recovers the 
original signature block in clear form, which is then 
parsed to recover the original hash value. The 

20 recovered hash value and the calculated hash val- 
ue are then compared for equality. If this compari- 
son is favorable, then DSIG is considered valid; 
otherwise, DSIG is not considered valid and IDK 
instruction 600 is aborted. The signature block re- 

25 covery and processing of course will depend on 
the method of digital signature implemented. In the 
description of the GKSP instruction it was indicated 
that the signature block may consist of the hash 
value and padding data or it may be constructed 

30 on the basis of a national or international standard, 
such as International Standards Organization draft 
international standard (ISO DIS) 9796. Those skilled 
in the art will appreciate that many possible im- 
plementations of the digital signature are possible 

35 and that the precise method of digital signatures is 
unimportant to the invention. What is important is 
that a method of digital signature is used in the 
preferred embodiment to ensure that the receiving 
cryptographic device can authenticate that the to- 

40 be-imported DEA key did in fact originate from a 
valid network cryptographic device. As the reader 
will also see, the digital signature is made an 
integral part of the GKSP and IDK instructions 
themselves, which ensures that the process of sig- 

45 nature production and signature verification occurs 
as part of the key export and key import processes 
and therefore the highest possible integrity over 
these processes is achieved. Although it is possible 
to perform signature production and signature ver- 

50 ification as separate instructions, which achieves 
complete compatibility with the present descrip- 
tions of the GKSP and IDK instructions, one also 
sees that less integrity is achieved. This is so 
because the signature generate instruction has no 

55 way to ensure that a key of the form ePU(keyblk) 
was in fact produced by the GKSP instruction. 

Keyblk recovery means 612 decrypts input 
ePU(keyblk), provided as an input to the IDK in- 
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struction at 603, under private key PR, provided as 
an output of PR recovery means 607. The recov- 
ered clear key block, keyblk, is provided as an 
output to both eKM.C6(K) production means 613 
and control information consistency checking 
means 61 4. 

Control information consistency checking 
means 614 checks the control information in the 
recovered keyblk output from keyblk recovery 
means 612 and the reference control information 
output from control information retrieval means 608 
for consistency. A first check consists in checking 
control vector C6 in keyblk for consistency with the 
reference control vector C6 supplied as an input to 
the IDK instruction at 605. This ensures that the 
receiving cryptographic application imports a key 
from with the expected or intended key usage 
attributes. In this case, reference control vector C6 
represents the expected control vector, whereas 
the recovered control vector C6 represents the 
actual control vector. The simplest form of consis- 
tency checking consists of checking these two con- 
trol vectors for equality. However, a more refined 
procedure is possible wherein attributes in the ref- 
erence control vector are allowed to override cor- 
responding attributes in the recovered control vec- 
tor. For example, the reference control vector could 
disable the ability to re-export the imported DEA 
key K t whereas the recovered control vector may 
or may not permit the imported DEA key K to be 
re-exported. More generally, the receiving device 
may disable any attribute granted within the re- 
ceived control vector. One will appreciate that tak- 
ing away a right is not the same as granting a right, 
which only the sending cryptographic device is 
permitted to do. The IDK instruction can be de- 
signed to permit this kind of control vector override 
or it may not, depending on the desires of the 
designer of the IDK instruction. A second check 
consists of checking the EID value in keyblk for 
equality with the reference EID value supplied as 
an input to the IDK instruction at 605. This ensures 
that the receiving cryptographic application imports 
a key from the expected or intended sending cryp- 
tographic device. In this case, the reference EID 
value is the EID of the intended sending cryp- 
tographic device, which is checked against the EID 
value in keyblk which represents the EID value of 
the actual sending cryptographic device. A third 
check consists of checking the EID value in keyblk 
for inequality with the EID value stored in the 
cryptographic facility of the receiving device. This 
ensures that the imported DEA K originated at 
another cryptographic device, i.e., that A can't im- 
port a K produced at A, that B can't import a K 
produced at B, etc. The usefulness of this check 
has been discussed previously. In all cases, if the 
consistency checking fails, then the IDK instruction 



is aborted. 

eKM.C6(K) production means 613 extracts the 
clear value of DEA key K and the control vector C6 
from keyblk, obtained as an output from the keyblk 

5 recovery means 612. and K is then encrypted 
under variant key KM.C6 formed as the Exclusive 
OR product of master key KM and control vector 
C6 recovered from C6 to produce the encrypted 
key value eKM.C6(K). In an alternative embodiment 

w where the reference control vector C6 can override 
the recovered control vector C6, the value of C6 
used to form the variant key KM.C6 can be the 
reference control vector C6. In yet another alter- 
native embodiment the IDK instruction itself can 

75 modify information in the control vector C6, so that 
K is encrypted with variant key KM.C6', where C6* 
is the IDK modified value of C6. In any event, the 
encrypted key eKM.C6(K) is returned to the CFAP 
as an instruction output at 61 5. 

20 The reader will appreciate that the IDK instruc- 
tion has been designed to perform consistency 
checking within the cryptographic facility in lieu of 
returning the recovered clear values of C6 and EID 
to the CFAP and performing this consistency 

25 checking outside of the cryptographic facility. In 
the preferred embodiment, this consistency check- 
ing is performed in the cryptographic facility hard- 
ware and the recovered clear values of C6 and EID 
are not exposed outside the CF. The reason for 

30 doing this is to ensure that the DEA key distribution 
channel does not also provide a covert privacy 
channel whereby secret data may be incorporated 
in the control information portion of the key block 
and transmitted from the sending cryptographic 

35 device to the receiving cryptographic device. In a 
good cryptographic design, the cryptographic 
instructions will perform only those cryptographic 
functions for which they were designed, and no 
more. Doing so, limits the ways in which an attac- 

40 ker can manipulate the cryptographic instructions 
for the purpose of subverting their intended secu- 
rity. For example, a system administrator in charge 
of security policy for the sending and recieving 
locations, may have a security policy which prohib- 

45 its the transmission of private messages over the 
communications link, for example when the link is 
dedicated merely to the transmission of new keys. 
In an alternate security policy where the system 
administrator is to selectively allow privacy chan- 

50 nels, there should be no "back door" method for 
subverting the system administrator's authority in 
enabling or prohibiting such privacy channels. The 
use of the control information transmitted over the 
separate channel to the receiver, is to enable the 

55 recipient to inspect the type of uses imposed on 
the receive key and allow the recipient the option 
of rejecting the keyblock. However, an alternate 
embodiment is possible wherein the recovered 



15 



27 



EP 0 529 261 A2 



28 



clear values of C6 and EID are returned to the 
CFAP and consistency checking is then performed 
by the CFAP. 

Control Information: Fig. 12 further illustrates 
the unique role played by the encrypted key block, 
ePU(keyblk), and the external key token. Although 
Figs. 5, 7, and 8 depict external key token as 
containing an encrypted key block of the form 
ePU(keyblk) and reference control information in 
clear form, in the logical sense there are two in- 
formation channels over which information flows: 
(1) and encrypted channel and (2) a clear channel. 
Referring now to Fig. 12, therein is shown two 
cryptographic systems, A and B, that communicate 
via a key distribution protocol through an encrypted 
channel 701 and a clear channel 702. Encrypted 
channel 701 is facilitated via the encrypted key 
block, ePU(keyblk). Control information in keyblk, 
which is subsequently encrypted with public key 
PL), is thus sent from A to B via an encrypted 
channel. Clear channel 702 is facilitated via the 
external key token. Control information in clear 
form stored in the external key token is, for all 
intents and purposes, passed from A to B via a 
clear channel. 

Another distinguishing feature of the two chan- 
nels is this. Encrypted channel 701 is a logical 
channel between the cryptographic facility 30 of 
cryptographic system A and cryptographic facility 
30' of cryptographic system B. Clear channel 702 
is a logical channel between application 36 in cryp- 
tographic system A and application 36* in cryp- 
tographic system B. and possibly a logical channel 
between CFAP 34 in cryptographic system A and 
CFAP 34* in cryptographic system B, depending on 
how the external key tokens are to be managed. In 
any event, the key distribution process is designed 
such that (1) in the case of encrypted channel 701, 
only the cryptographic facilities have access to the 
control information in keyblk, whereas (2) in the 
case of clear channel 702, the applications and 
possibly the CFAPs have access to the control 
information in the external key token as a routine 
part of the key distribution protocol. Since the CF 
is typically implemented within secure hardware, 
the CF is said to have a higher level of integrity 
than other parts of the the cryptographic system, 
such as the CFAP and applications operating within 
the cryptographic system. Thus, a higher degree of 
protection is achieved within the key distribution 
process by controlling that process, to the degree 
possible, from within the CF itself. To this end, 
control information is passed via encrypted channel 
701, in keyblk, from A to B, thus enabling B to 
process the imported keyblk with a high degree of 
integrity. Of course, the assumption is made here 
that digital signatures are also a part of the key 
distribution process, as shown in Fig. 8, which 



forms another underpinning or layer of integrity that 
augments and enhances the overall integrity of 
information passed via encrypted channel 701 . 
Fig. 13 illustrates the process of reconciliation 

5 between control information transmitted via encryp- 
ted channel 701 and control information, called 
reference control information, transmitted via clear 
channel 702. The importance in having these two 
channels for passing control information can now 

10 be seen. Control information transmitted via en- 
crypted channel 701 can be 'seen' by the cryp- 
tographic facility, but by no one outside the cryp- 
tographic facility. This ensures that the key dis- 
tribution channel is not used as a covert privacy 

75 channel. Thus, the only way that the application 
program or the CFAP has of validating the control 
information transmitted via encrypted channel 701 
is the specify reference control information to the 
CF in clear form. Since it is the application pro- 

20 gram or the CFAP that specifies the reference 
control information, the reference control informa- 
tion is consistency checked to determine its accu- 
racy before being passed to the CF. Inside the 
protected boundary of the CF, the control informa- 

25 tion recovered from the decrypted keyblk is 
checked for consistency with the reference control 
information supplied in clear form by the applica- 
tion to the CFAP and thence by the CFAP to the 
CF. This permits all parties (CF, CFAP, and ap- 

30 plication) to be sure that the the control information 
associated with the to-be-imported key is correct 
and in accordance with expectations. In summary, 
all parties look at the reference control information 
and have a chance to agree or disagree with it, but 

35 only the CF sees the control information passed in 
keyblk and only the CF with highest integrity deter- 
mines whether the control information received via 
encrypted channel 701 (i.e., in keyblk) is consistent 
with the reference control information received in 

40 the external key token by the application, or by the 
CFAP depending on whether key distribution is 
implemented at the application layer or at the cryp- 
tographic facility access program layer. Referring 
now to Rg. 13, reference control information 

45 (designated RCI) received via Clear Channel 702 is 
inspected by the receiving application program 
APPL 36. If APPL 36 finds the reference control 
information to be okay, i.e., it is accurate accept- 
able, and in accordance with the protocol, in all 

so respects, then APPL 36 will issue a request to 
CFAP 34 to import the received DEA key, passing 
the reference control information in the received 
external key token to CFAP 34. If the CFAP 34 
finds the reference control information to be okay, 

55 then CFAP 36 will issue an IDK instruction to CF 
30 to import the received DEA key, passing the 
reference control information in the received exter- 
nal key token to CF 30. The control information 
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(designated CI) received via Encrypted Channel 
701 and the reference control information RCI re- 
ceived from the CFAP 34 are inspected by them- 
selves for consistency and then they are compared 
or consistency checked, one against the other, to 
determine that CI is consistent with RCI. Only if 
this consistency checking succeeds, will the CF 30 
import the DEA key. 

Fig. 14 is a block diagram of the cryptographic 
facility 30 in the sending location A, as it is or- 
ganized for performing the generate key set PKA 
(GKSP) instruction, illustrated in Fig. 9. Fig. 14 
shows the cryptographic facility 30 at the sending 
location which includes* the crypto variable retrieval 
means 40, shown in greater detail in Fig. 16. To 
prepare a crypto variable such as the key K for 
transmission from the cryptographic facility 30 to 
the cryptographic facility 30' at the receiving loca- 
tion, the key K is accessed from the crypto variable 
retrieval means 40 over the line 62 and applied to 
the concatenation means 42. In addition, control 
information such as a control vector and an envi- 
ronmental identification are accessed over line 60 
from the crypto variable retrieval means 40 and are 
applied to the concatenation means 42. Concatena- 
tion means 42 will concatenate the key K with the 
control vector and the environmental identification 
and that will form the key block 80 which is applied 
to the public key algorithm encryption means 44. 
The public key is accessed over line 70 from the 
crypto variable retrieval means 40 and is applied to 
the key input of the encryption means 44. The key 
block 80 is encrypted forming the encrypted key 
block 85 which is then applied to the transmitting 
means 46. The encrypted key block 85 is then 
transmitted over the transmission link 12 to the 
cryptographic facility 30' at the receiving location 
shown in Fig. 15. The control information consisting 
of the control vector and the environmental iden- 
tification which has been accessed over line 60 is 
also output as a separate information unit to the 
transmitting means 46 for transmission over the 
link 12 to the cryptographic facility 30* at the re- 
ceiving location. The control information, which can 
be referred here as the reference control informa- 
tion, is separate from the encrypted key block 85. 
The reference control information can be transmit- 
ted over the same physical communications link 12 
as the encrypted key block 85, in a different time 
slot or frequency slot in the case of frequency 
division multiplexing. Alternately, completely sepa- 
rate physical communication links can be em- 
ployed to transmit the reference control information 
as distinguished from the transmission of the en- 
crypted key block 85. The transmission of the 
reference control information can be in either clear 
text form, or alternately the reference control in- 
formation can be encrypted and transmitted over a 



privacy channel if the sender and receiver share 
suitable keys. 

In the receiving cryptographic facility 30' 
shown in Fig. 15, the reference control information 

5 is transferred from the communications link 12 to 
the overline 74 to the control information compari- 
son means 59. The encrypted key block 85 is 
transferred from the receiving means 56 to the 
public key algorithm decryption means 54. A pri- 

w vacy key is accessed over line 72 from the crypto 
variable retrieval means 40' and is applied to the 
key input of the decryption means 54. The opera- 
tion of the decryption means 54 generates the 
recovered key block 80 which is applied to the 

J5 extraction means 52. The extraction means 52 ex- 
tracts the control information 60 from the recovered 
key block 80 and applies the extracted control 
information to the control information comparison 
means 59. The control information comparison 

20 means 59 then compares the identity of the ex- 
tracted control information from the key block 80 
with the reference control information received from 
the communications link 12 over line 74. The con- 
trol information comparison means 59 has an en- 

25 abling output signal 90 which is produced if the 
comparison is satisfied. The enabling sfgnal 90 is 
applied to an enabling input of the crypto variable 
storage means 50. The crypto variable, in this 
example the key K, is output from the extraction 

30 means 52 on line 62 and applied to the crypto 
variable storage means 50. The key K will be 
successfully stored in a crypto variable storage 
means 50 if the enabling signal 90 is applied from 
the comparison means 59. In addition, the control 

35 information which can include the control vector 
and the environmental ID of the sending location, 
can also be stored in the crypto variable storage 
means 50, if the enabling signal 90 is present. 
Further in accordance with the invention, a 

40 comparison can be made between the environmen- 
tal ID of the receiving station B and the envi- 
ronmental ID of the transmitting station A, in order 
to ensure that the environmental ID for the receiv- 
ing station B is not identical with the environmental 

45 ID contained in the recovered key block 80. This 
comparison can also be performed in the compari- 
son means 59 and the successful comparison can 
be made necessary to the generation of the en- 
abling signal 90 as described above. The envi- 

so ronmental ID in the reference control information 
should successfully compare with the environmen- 
tal ID extracted by the extraction means 52 from 
the key block 80. In addition, the environmental ID 
extracted from the key block 80, which represents 

55 the environmental ID of the sending location A, 
should not be the same as the environmental ID of 
the receiving station B. When these two conditions 
exist and also when the control vector in the refer- 

17 
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ence control information successfully compares 
with the control vector extracted by the extraction 
means 52 from the key block 80, then the compari- 
son means 59 will output an enabling signal 90 to 
the storage means 50. 5 

The crypto variable retrieval means 40 and 40' 
is shown in greater detail in Fig. 16. Input param- 
eters 31 1 can be transferred over line 33 from the 
externa! storage 400 in the CFAP 34. These input 
parameters can then be applied to the crypto fa- 10 
cility 30, over lines 31. Op codes 310 in the CFAP 
34 can also be applied over lines 31 to the crypto 
facility 30. The crypto facility 30 includes the 
crypto variable retrieval means 40 which contains a 
random number generator 95, a data encryption 75 
algorithm decryption means 410 and an output 
selection means 420. A master key storage 99 is 
contained in the crypto facility 30, having an output 
connected to the key input of the decryption 
means 410. The random number generator 95 can 20 
generate a first type key K' to be applied to the 
output selection means 420. Alternately, a second 
type key K" in clear text form can be applied to the 
output selection means 420. Alternately, a third 
type key K'" can be applied to the output selection 25 
means 420, which is derived from the decryption 
by the decryption means 410 of an encrypted form 
of the key K 1M which has been encrypted under the 
exclusive OR product of the master key KM and 
the control vector C5. The output of the selection 30 
means 420 is the key K which is the crypto vari- 
able which is discussed in relation to Figs. 14 and 
15. 

In the preferred embodiment of the invention, 
public key encryption is used as the encryption 35 
technique for transmitting the key block from the 
sending location to the receiving location, however, 
it is within the scope of the invention to use sym- 
metric, private key techniques for enciphering and 
deciphering the key block. Also, in the preferred 40 
embodiment of the invention, where digital signa- 
tures are employed, as described above, the public 
key encryption technique for forming digital signa- 
tures is employed. However, in an alternate em- 
bodiment, conventional Message Authentication 45 
Code (MAC) techniques may be employed using a 
private key algorithm. In the preferred embodiment 
of the invention, Data Encryption Standard (DES) 
key is the crypto variable which is transmitted in 
the key block from the sending location to the so 
receiving location, however, in alternate embodi- 
ments of the invention, the crypto variable can be a 
public key or a non-key-type expression. 

Although a specific embodiment of the inven- 
tion has been disclosed, it will be understood by 55 
those having skill in the art that changes can be 
made to the specific embodiment without departing 
from the spirit and the scope of the invention. 



Claims 

1. In a data processing system having a plurality 
of communicating nodes, at least a pair of 
nodes in the system exchanging cryptographic 
communications, an apparatus for enabling a 
first node of the pair to control a crypto vari- 
able after its transmission from the first node 
to a second node of the pair, comprising: 

a storage means at a transmitting node in the 
system for storing a crypto variable which is to 
be transmitted to a receiving node in the sys- 
tem; 

said storage means storing control information 
including a control vector to control said crypto 
variable after it is transmitted from said trans- 
mitting node; 

said storage means storing a first key expres- 
sion; 

concatenating means at said transmitting node, 
coupled to said storage means, for concatenat- 
ing said crypto variable with said control in- 
formation, forming a key block; 

encryption means at said transmitting node, 
coupled to said storage means and said con- 
catenating means, for encrypting said key 
block with said first key expression, forming an 
encrypted key block; and 

transmitting means at said transmitting node 
coupled to said encryption means and coupled 
over a communications link to a receiving 
means at said receiving node, for transmitting 
said encrypted key block to said receiving 
node. 

2. In a data processing system having a plurality 
of communicating nodes, at least a pair of 
nodes in the system exchanging cryptographic 
communications, an apparatus for enabling a 
first node of the pair to control a crypto vari- 
able after its transmission from the first node 
to a second node of the pair, comprising: 

a first storage means at a transmitting node in 
the system for storing a crypto variable which 
is to be transmitted to a receiving node in the 
system; 

a second storage means at said transmitting 
node for storing control information to control 
said crypto variable after it is transmitted from 
said transmitting node said control information 
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including a control vector to limit the uses of 
said crypto variable; 

a third storage means at said transmitting node 
for storing a first key expression; 5 

concatenating means at said transmitting node, 
coupled to said first and second storage 
means, for concatenating said crypto variable 
with said control information, forming a key w 
block; 

encryption means at said transmitting node, 
coupled to said third storage means and said 
concatenating means, for encrypting said key is 
block with said first key expression, forming an 
encrypted key block; 

transmitting means at said transmitting node 
coupled to said encryption means and coupled 20 
over a communications link to a receiving 
means at said receiving node, for transmitting 
said encrypted key block to said receiving 
node; 

25 

said transmitting means coupled to said sec- 
ond storage means, for transmitting a second 
copy of said control information to said receiv- 
ing node; 

30 

fourth storage means at said receiving node, 
for storing a second key expression corre- 
sponding to said first key expression; 

decryption means at said receiving node coup- 35 
led to said receiving means and to said fourth 
storage means, for decrypting said encrypted 
key block using said second key expression, 
to obtain a recovered key block; 

40 

extraction means at said receiving node coup- 
led to said decryption means, to extract said 
control information and said crypto variable 
from said recovered key block; 

45 

comparison means at said receiving node 
coupled to said extraction means and coupled 
to said receiving means for comparing said 
control information extracted from said recov- 
ered key block to said second copy of said 50 
control information, said comparison means 
having an enabling output for signalling when 
said comparison is satisfied; 

control means coupled to said extraction 55 
means and having an enabling input coupled 
to said output of said comparison means, for 
controlling said crypto variable with said con- 



trol information. 

3. Apparatus for generating and distributing a 
Data Encryption Algorithm (DEA) key in a com- 
munications network, comprising: 

a) sending means for generating and pro- 
ducing at least two copies of a key-encryp- 
ting key (k-ek), and control information in- 
cluding a control vector for permitted uses 
of the k-ek; 

b) means included in the sending means for 
encrypting one copy of the k-ek under the 
public key of a receiving means and trans- 
mitting the public key encrypted k-ek to the 
receiving means in association with said 
control information; 

c) means further included in the sending 
means for encrypting another copy of the k- 
ek under a master key of the sending 
means; 

d) means further included in the sending 
means for storing the master key encrypted 
k-ek as a common distributing key for other 
encrypted keys used in the network, in as- 
sociation with said control information; 

e) control means included in the sending 
means, to limit uses of the k-ek to said 
permitted uses in response to said control 
information. 

4. The apparatus of claim 1, 2, or 3, wherein: 

said first key expression and said second key 
expression being symmetric keys, and/or 
wherein 

said first key expression being a public key 
issued by said receiving node and said second 
key expression being a private key corre- 
sponding to said public key. 

5. The apparatus of anyone of the proceeding 
claims, wherein said control means further 
comprises: 

a reference storage means at said receiving 
node for storing a reference control vector 
characterizing required uses of said crypto 
variable at said receiving station; 

a received control vector storage means at 
said receiving node, coupled to said extraction 
means, for storing said received control vector 
extracted from said recovered key block; 

said comparison means at said receiving node 
coupled to said reference storage means and 
to said received control vector storage means, 
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for comparing said reference control vector 
with said received control vector, and output- 
ting an acceptance signal if the comparison 
succeeds; 

5 

crypto variable storage means at said receive 
node coupled to said extraction means and to 
said comparison means, for storing said crypto 
variable extracted by said extraction means if 
said acceptance signal is received from said 10 
compare means. 

6. The apparatus of claim 5, wherein said crypto 
variable storage means further comprises: 

T5 

a master key storage means at said receiving 
node for storing a master key; 

an exclusive OR means at said receiving node 
coupled to said master key storage means and 20 
to said received or reference control vector 
storage means respectively, for forming an ex- 
clusive OR product of said master key and 
said received or reference control vector, re- 
spectively, forming a product key expression; 25 

an encryption engine at said receiving node 
having a key input coupled to said exclusive 
OR means for inputting said product key ex- 
pression, and having an operand input coupled 30 
to said crypto variable storage means, for en- 
crypting said crypto variable under said master 
key, forming an encrypted crypto variable; 

an encrypted crypto variable storage means at 35 
said receiving node, coupled to said encryption 
engine, for storing said encrypted crypto vari- 
able. 

7. The apparatus of claim 6, which further com- aq 
prises: 

a control vector checking means at said receiv- 
ing node coupled to a user input, for receiving 
a request from a user for using said crypto 45 
variable; 

said control vector checking means being 
coupled to said received control vector storage 
means, for checking said received control vec- so 
tor to determine if said requested uses are 
permitted; 

said control vector checking means outputting 

an enabling signal if said requested uses are 55 

permitted; 

a processing means at said receiving node 



coupled to said control vector checking means, 
to said received control vector storage means 
and to said master key storage means, for 
receiving said enabling signal and in response 
thereto, forming an exclusive OR product of 
said master key and said received control vec- 
tor, forming a product key expression; 

a decryption engine at said receiving node 
having a key input coupled to said exclusive 
OR means for inputting said product key ex- 
pression, and having an operand input coupled 
to said encrypted crypto variable storage 
means, for decrypting said encrypted crypto 
variable under said master key, recovering 
said crypto variable. 

8. The apparatus of claim 6 or 7, which further 
comprises: 

a control vector checking means at said receiv- 
ing node coupled to a user input, for receiving 
a request from a user for using said crypto 
variable; 

said control vector checking means being 
coupled to said reference control vector stor- 
age means, for checking said reference control 
vector to determine if said requested uses are 
permitted; 

said control vector checking means outputting 
an enabling signal if said requested uses are 
permitted; 

a processing means at said receiving node 
coupled to said control vector checking means, 
to said reference control vector storage means 
and to said master key storage means, for 
receiving said enabling signal and in response 
thereto, forming an exclusive OR product of 
said master key and said reference control 
vector, forming a product key expression; 

a decryption engine at said receiving node 
having a key input coupled to said exclusive 
OR means for inputting said product key ex- 
pression, and having an operand input coupled 
to said encrypted crypto variable storage 
means, for decrypting said encrypted crypto 
variable under said master key, recovering 
said crypto variable; 

wherein said reference control vector is re- 
ceived preferably from said transmitting node. 

9. The apparatus of claim 8, which further com- 
prises: 
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said received control vector is a first hashed 
product of said reference control vector, re- 
ceived from said transmitting node; 

hashing means in said receiving node coupled 
to said reference control vector storage means, 
for forming a second hash product of said 
reference control vector; 

second comparison means coupled to said re- 
ceived control vector storage means and to 
said hashing means, for comparing said first 
hashed product with said second hashed prod- 
uct and outputting a second acceptance signal 
when the comparison is satisfied. 

10. The apparatus of anyone of claims 1 to 4, 
which further comprises: 

said control information includes a hashed con- 
trol vector which represents limitations on uses 
of said crypto variable. 

11. The apparatus of claim 10, wherein said con- 
trol means further comprises: 

a reference control vector storage means at 
said receiving node for receiving from said 
transmitting node and storing a reference con- 
trol vector characterizing required uses of said 
crypto variable at said receiving station; 

a hashed control vector storage means at said 
receiving node, coupled to said extraction 
means, for storing said hashed control vector 
extracted from said recovered key block; 

hashing means in said receiving node coupled 
to said reference control vector storage means, 
for forming a hash product of said reference 
control vector; 

compare means at said receiving node coup- 
led to said hashing means and to said hashed 
control vector storage means, for comparing 
said hash product with said hashed control 
vector, and outputting an acceptance signal if 
the comparison succeeds; 

crypto variable storage means at said receive 
node coupled to said extraction means and to 
said compare means, for storing said crypto 
variable extracted by said extraction means if 
said acceptance signal is hashed from said 
compare means. 



12. The apparatus of claim 11, wherein said crypto 
variable storage means further comprises: 

a master key storage means at said receiving 
5 node for storing a master key; 

an exclusive OR means at said receiving node 
coupled to said master key storage means and 
to said hashed control vector storage means, 
w for forming an exclusive OR product of said 
master key and said hashed control vector, 
forming a product key expression; 

an encryption engine at said receiving node 
75 having a key input coupled to said exclusive 
OR means for inputting said product key ex- 
pression, and having an operand input coupled 
to said crypto variable storage means, for en- 
crypting said crypto variable under said master 
20 key, forming an encrypted crypto variable; 

an encrypted crypto variable storage means at 
said receiving node, coupled to said encryption 
engine, for storing said encrypted crypto vari- 
25 able. 

13. The apparatus of claim 12, which further com- 
prises: 

30 a control vector checking means at said receiv- 
ing node coupled to a user input, for receiving 
a request from a user for using said crypto 
variable; 

35 said control vector checking means being 
coupled to said reference control vector stor- 
age means, for checking said reference control 
vector to determine if said requested uses are 
permitted; 

40 

said control vector checking means outputting 
an enabling signal if said requested uses are 
permitted; 

45 a processing means at said receiving node 

coupled to said control vector checking means, 
to said hashed control vector storage means 
and to said master key storage means, for 
receiving said enabling signal and in response 

so thereto, forming an exclusive OR product of 
said master key and said hashed control vec- 
tor, forming a product key expression; 

a decryption engine at said receiving node 
55 having a key input coupled to said exclusive 
OR means for inputting said product key ex- 
pression, and having an operand input coupled 
to said encrypted crypto variable storage 
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means, for decrypting said encrypted crypto 
variable under said master key, recovering 
said crypto variable. 

14. The apparatus of anyone of the preceeding 
claims, which further comprises: 

said control information includes a transmitting 
node environment identification which charac- 
terizes the identity of said transmitting node. 

15. The apparatus of claim 14, wherein said con- 
trol means further comprises: 

a receiving node environment identification 
storage means at said receiving node for stor- 
ing a receiving node environment identification; 

a received transmission node environment 
identification storage means at said receiving 
node, coupled to said extraction means, for 
storing said transmitting node environment 
identification extracted from said recovered 
key block; 

compare means at said receiving node coup- 
led to said receiving node environment iden- 
tification storage means and to said received 
transmission node environment identification 
storage means, for comparing said receiving 
node environment identification and said trans- 
mitting node environment identification and 
outputting an acceptance signal if the compari- 
son fails; 

crypto variable storage means at said receive 
node coupled to said extraction means and to 
said compare means, for storing said crypto 
variable extracted by said extraction means if 
said acceptance signal is received from said 
compare means. 

16. In a data processing system having a plurality 
of communicating nodes, at least a pair of 
nodes in the system exchanging cryptographic 
communications, a method for enabling a first 
node of the pair to control a crypto variable 
after its transmission from the first node to a 
second node of the pair, comprising: 

storing a crypto variable which is to be trans- 
mitted to a receiving node in the system, at a 
transmitting node; 

storing control information to control said 
crypto variable after it is transmitted from said 
transmitting node, at said transmitting node 
said control information including a control 



vector to limit the uses of said crypto variable; 

storing a first key expression at said transmit- 
ting node; 

5 

concatenating said crypto variable with said 
control information, forming a key block, at 
said transmitting node; 

10 encrypting said key block with said first key 

expression, forming an encrypted key block, at 
said transmitting node; 

transmitting said encrypted key block to said 
75 receiving node; 

transmitting a second copy of said control in- 
formation to said receiving node; 

20 storing a second key expression corresponding 

to said first key expression, at said receiving 
node; 

decrypting said encrypted key block using said 
25 second key expression, to obtain a recovered 

key block, at said receiving node; 

extracting said control information and said 
crypto variable from said recovered key block, 
30 at said receiving node; 

comparing said control information extracted 
from siad recovered key block with said sec- 
ond copy of said control information and gen- 
35 erating an enabling signal when the compare is 

satisfied; 

controlling said crypto variable with said con- 
trol information when said enabling signal has 
40 been generated, 

17. In a data processing system having a plurality 
of communicating nodes, at least a pair of 
nodes in the system exchanging cryptographic 
45 communications, a method for enabling a first 

node of the pair to control a crypto variable 
after its transmission from the first node to a 
second node of the pair, comprising: 

so concatenating a crypto variable with control 
information including a control vector to control 
said crypto variable after it is transmitted from 
said transmitting node, forming a key block, at 
said transmitting node; 

55 

encrypting said key block with a first key ex- 
pression, forming an encrypted key block, at 
said transmitting node; 
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transmitting said encrypted key block to said 
receiving node; 

decrypting said encrypted key block using a 5 
second key expression, to obtain a recovered 
key block, at said receiving node; 

extracting said control information and said 
crypto variable from said recovered key block, w 
at said receiving node; 

validating said control information extracted 
from said recovered key block and generating 
an enabling signal; 75 

controlling said crypto variable with said con- 
trol information when said enabling signal has 
been generated. 

18. In a data processing system having a plurality 
of communicating nodes, at least a pair of 
nodes in the system exchanging cryptographic 
communications, a program for execution on 
the data processing system for enabling a first 
node of the pair to control a crypto variable 
after its transmission from the first node to a 
second node of the pair, comprising: 

said program controlling the data processing 30 
system for storing a crypto variable which is to 
be transmitted to a receiving node in the sys- 
tem, at a transmitting node; 

said program controlling the data processing 
system for storing control information to con- 
trol said crypto variable after it is transmitted 
from said transmitting node, at said transmit- 
ting node said control information including a 
control vector to limit the uses of said crypto 
variable; 

said program controlling the data processing 
system for storing a first key expression at 
said transmitting node; 45 

said program controlling the data processing 
system for concatenating said crypto variable 
with said control information, forming a key 
block, at said transmitting node; so 

said program controlling the data processing 
system for encrypting said key block with said 
first key expression, forming an encrypted key 
block, at said transmitting node; 55 

said program controlling the data processing 
system for transmitting said encrypted key 



block to said receiving node; 

said program controlling the data processing 
system for transmitting a second copy of said 
control information to said receiving node; 

said program controlling the data processing 
system for storing a second key expression 
corresponding to said first key expression, at 
said receiving node; 

said program controlling the data processing 
system for decrypting said encrypted key 
block using said second key expression, to 
obtain a recovered key block, at said receiving 
node; 



said program controlling the data processing 
system for controlling said crypto variable with 
said control information when said enabling 
signal has been generated. 



said first key expression being a public key 
issued by said receiving node and said second 
key expression being a private key corre- 
sponding to said public key. 

20. The method of claim 16, 17, or the program of 
claim 18 or 19, which further comprises: 

said control information includes a received 
control vector which defines limitations on uses 
of said crypto variable. 

21. The program of claim 20, which further com- 
prises: 

said program controlling the data processing 
system for storing a reference control vector 
characterizing required uses of said crypto 



said program controlling the data processing 
system for extracting said control information 
20 and said crypto variable from said recovered 
key block, at said receiving node; 

said program controlling the data processing 
system for comparing said control information 
25 extracted from said recovered key block with 

said second copy of said control information 
and generating an enabling signal when the 
compare is satisfied; 



35 19. The method of claim 16 or 17, or the program 
of claim 18, which further comprises: 

said first key expression and said second key 
expression being symmetric keys, and/or 

AO 
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variable at said receiving node; 

said program controlling the data processing 
system for storing said received control vector 
extracted from said recovered key block, at 5 
said receiving node; 

said program controlling the data processing 
system for comparing said reference control 
vector with said received control vector, and w 
outputting an acceptance signal if the compari- 
son succeeds, at said receiving node; 

said program controlling the data processing 
system for storing said crypto variable ex- 75 
tracted by said extraction means if said accep- 
tance signal is received from said compare 
means, at said receiving node. 

22. The program of claim 21, which further com- 20 
prises: 

said program controlling the data processing 
system for storing a master key at said receiv- 
ing node; 25 

said program controlling the data processing 
system for forming an exclusive OR product of 
said master key and said received control vec- 
tor, forming a product key expression, at said 
receiving node; 

said program controlling the data processing 
system for encrypting said crypto variable un- 
der said master key, forming an encrypted 35 
crypto variable, at said receiving node; 

said program controlling the data processing 
system for storing said encrypted crypto vari- 
able, at said receiving node. 40 

23. The program of claim 22, which further com- 
prises: 

said program controlling the data processing 45 
system for receiving a request from a user for 
using said crypto variable, at said receiving 
node; 

said program controlling the data processing 50 
system for checking said received control vec- 
tor to determine if said requested uses are 
permitted, at said receiving node; 

said program controlling the data processing 55 
system for outputting an enabling signal if said 
requested uses are permitted, at said receiving 
node; 



said program controlling the data processing 
system for receiving said enabling signal and 
in response thereto, forming an exclusive OR 
product of said master key and said received 
control vector, forming a product key expres- 
sion, at said receiving node; 

said program controlling the data processing 
system for inputting said product key expres- 
sion, and decrypting said encrypted crypto 
variable under said master key, recovering 
said crypto variable, at said receiving node. 

24. The program of claim 21, which further com- 
prises: 

said program controlling the data processing 
system for storing a master key at said receiv- 
ing node; 

said program controlling the data processing 
system for forming an exclusive OR product of 
said master key and said reference control 
vector, forming a product key expression, at 
said receiving node; 



said program controlling the data processing 
system for storing said encrypted crypto vari- 
able, at said receiving node. 

25. The program of claim 24, which further com- 
prises: 

said program controlling the data processing 
system for receiving a request from a user for 
using said crypto variable, at said receiving 
node; 

said program controlling the data processing 
system for checking said reference control 
vector to determine if said requested uses are 
permitted, at said receiving node; 

said program controlling the data processing 
system for outputting an enabling signal if said 
requested uses are permitted, at said receiving 
node; 

said program controlling the data processing 
system for receiving said enabling signal and 
in response thereto, forming an exclusive OR 



said program controlling the data processing 
system for inputting said product key expres- 
30 sion, and encrypting said crypto variable under 

said master key, forming an encrypted crypto 
variable, at said receiving node; 
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product of said master key and said reference 
control vector, forming a product key expres- 
sion, at said receiving node; 

said program controlling the data processing 5 
system for decrypting said encrypted crypto 
variable under said master key, recovering 
said crypto variable, at said receiving node; 

wherein said reference control vector is re- w 
ceived preferably from said transmitting node. 

26. The program of claim 25, which further com- 
prises: 

75 

said received control vector is a first hashed 
product of said reference control vector, re- 
ceived from said transmitting node; 

said program controlling the data processing 20 
system for forming a second hash product of 
said reference control vector, at said receiving 
node; 

said program controlling the data processing 25 
system for comparing said first hashed product 
with said second hashed product and output- 
ting a second acceptance signal when the 
comparison is satisfied, at said receiving node. 

30 

27. The program of claim 20, which further com- 
prises: 

said control information includes a hashed con- 
trol vector which represents limitations on uses 35 
of said crypto variable. 

28. The program of claim 27, wherein said control 
means further comprises: 

40 

said program controlling the data processing 
system for receiving from said transmitting 
node and storing a reference control vector 
characterizing required uses of said crypto 
variable at said receiving station, at said re- 45 
ceiving node; 

said program controlling the data processing 
system for storing said hashed control vector 
extracted from said recovered key block, at so 
said receiving node; 

said program controlling the data processing 
system for forming a hash product of said 
reference control vector, at said receiving 55 
node; 

said program controlling the data processing 



system for comparing said hash product with 
said hashed control vector, and outputting an 
acceptance signal if the comparison succeeds, 
at said receiving node; 

said program controlling the data processing 
system for storing said crypto variable ex- 
tracted by said extraction means if said accep- 
tance signal is hashed from said compare 
means, at said receiving node. 

29. The program of claim 28, which further com- 
prises: 

said program controlling the data processing 
system for storing a master key at said receiv- 
ing node; 

said program controlling the data processing 
system for forming an exclusive OR product of 
said master key and said hashed control vec- 
tor, forming a product key expression* at said 
receiving node; 

said program controlling the data processing 
system for inputting said product key expres- 
sion, and encrypting said crypto variable under 
said master key, forming an encrypted crypto 
variable, at said receiving node; 

said program controlling the data processing 
system for storing said encrypted crypto vari- 
able, at said receiving node. 

30. The program of claim 29, which further com- 
prises: 

said program controlling the data processing 
system for receiving a request from a user for 
using said crypto variable, at said receiving 
node; 

said program controlling the data processing 
system for checking said reference control 
vector to determine if said requested uses are 
permitted, at said receiving node; 

said program controlling the data processing 
system for outputting an enabling signal if said 
requested uses are permitted, at said receiving 
node; 

said program controlling the data processing 
system for receiving said enabling signal and 
in response thereto, forming an exclusive OR 
product of said master key and said hashed 
control vector, forming a product key expres- 
sion, at said receiving node; 
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said program controlling the data processing 
system for inputting said product key expres- 
sion, and decrypting said encrypted crypto 
variable under said master key, recovering 5 
said crypto variable, at said receiving node. 

31. The method or the program of anyone of the 
claims 16 to 30, which further comprises: 

70 

said control information includes a transmitting 
node environment identification which charac- 
terizes the identity of said transmitting node. 

32. The program of claim 31, which further com- 75 
prises: 

said program controlling the data processing 
system for storing a receiving node environ- 
ment identification, at said receiving node; 20 

said program controlling the data processing 
system for storing said transmitting node envi- 
ronment identification extracted from said re- 
covered key block, at said receiving node; 25 

said program controlling the data processing 
system for comparing said receiving node en- 
vironment identification and said transmitting 
node environment identification and outputting 30 
an acceptance signal if the comparison fails, at 
said receiving node; 

said program controlling the data processing 
system for storing said crypto variable ex- 35 
tracted by said extraction means if said accep- 
tance signal is received from said compare 
means, at said receiving node. 
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